Derivation and use of trust and risk management parameters in dynamic federated environments

Traditionally, the risks associated with granting customers and their users access to services and resources are mitigated by contractual frameworks, such as service level agreements (SLAs). However, in large and highly dynamic federated environments, also external and previously unknown users must be handled in an automated manner, which limits the available options to negotiate SLAs. In this paper we present how risk management on the service provider side and user trust level management frameworks can be combined and applied to policy-based access control mechanisms. 1 Motivation for managing risk and trust in dynamic federated environments Specifying quality of service parameters and penalties for not fulfilling them is a classical approach to mitigate several of the customer’s and the service provider’s risks resulting from inter-organizational dependencies and business connections. Service level management and its interfaces to other IT service management (ITSM) processes, especially financial and security management, have been motivated, analyzed, and improved by both researchers and practitioners over the past decades and are impossible to imagine away today. However, new services, such as distributed collaborative environments, have such high dynamics and fluctuation regarding involved organizations, resources, and users that new technical measures are required to improve the reactivity of ITSM workflows and thus support the underlying business processes. In this paper, we present a risk based resource protection approach for dynamic federated environments (DFEs), i. e. for inter-organizational scenarios in which the involved entities are bound by a contractual framework but must support the temporary inclusion of external entities. Rather obviously, this results in new requirements for access control mechanisms on the service operation level, because even although sharing resources in such environments must be quick to set up, misuse and unauthorized access must still be detectable and preventable by proper configuration. Characterized by the locality over globality paradigm, the service providers as resource owners must have the possibility to determine how, when, and which resources are available for which kind of access by whom. Granting permissions to a customer’s users, which is typically regulated by service level agreements (SLAs), reflects that each of these users is sufficiently trusted and that the risk of incidents caused by the users is outweighted by the mutual benefits. Various access control models have successfully been applied to intra-organizational scenarios and have later been extended for inter-organizational and federation scenarios. Several variants of standards like role based access control (RBAC) and its successors, e. g. attribute based access control (ABAC), allow the delegation of administration on the one hand and privileges on the other hand; unfortunately, only seemingly they are a good starting point for the inclusion of external entities in DFEs, because privileges may only be delegated to those principals which are already known in the federation. This means that a digital identity that has been created by one of the involved organizations must be assigned to the user a priori, which causes the very same timeliness, cost, and complexity problems we strive to avoid. The new approach presented in this paper is based upon our previous work on trust based access management (TBAC) and proposes the combined use of both, formulabased trust quantification and risk assessment, in dynamic access control policies. In DFEs, an external principal may be vouched for by one or more known entities, which themselves may or may not be members of the federation; deriving from how trustworthy each warrantor is, an initial trust level for the external principal can be calculated. This trust level changes over time, typically based on feedback and recommendation mechanisms known from reputation management; however, service providers must always consider the risk of granting resource access to previously unknown users and cannot afford to rely solely on vague trust recommendations, especially because several reputation management approaches that were used in e-commerce environments turned out to be bogus or susceptible to fraud. The remainder of this paper is structured as follows: In the next section we outline a DFE scenario which serves as an example in the presentation of our risk-based management approach in section 3. Our data model, which is to be used in dynamic access control approaches, and our RDF/LDAP-based implementation are discussed in section 4. Competitive approaches and related work are summed up in section 5; the paper is concluded by a discussion of the current status as well as the next steps of our work. 2 Real-world scenario: Distributed eLearning federations To illustrate the importance of risk assessment on the one hand and the application area of our solution on the other hand, we present a simplified view of a real-world eLearning scenario in the MNM-Team’s environment. Two of the Munich universities, LMU and TUM, offer several joint study courses, e. g. medicine and bio-informatics; students of these study courses are enrolled in both universities and thus must be able to use both universities’ IT services, including the learning management systems (LMS). Additionaly, more than 30 higher education institutions (HEIs) in the German state of Bavaria are carriers of the so-called Virtual University Bavaria (VHB); the VHB acts as a broker between the students and each HEI’s local LMS, which results in a highly distributed federated environment with a focus on eLearning services. Given the naturally high fluctuation of students and the regular changes concerning which eLearning courses are offered, this scenario represents a DFE as discussed in the introduction. Regarding the SLA for a typical LMS and the privileges derived thereof, we naturally need to distinguish between users and resources. Resources include the various types of LMS content, e. g. lecture notes, exercises, and presentation slides. To handle the masses of users efficiently, RBAC roles, such as students, lecturer, and LMS administrator, are defined. It is noteworthy that the same terminology for at least a subset of the RBAC roles is also used for the description of business roles, which are utilized in the textual formulation of SLAs; for large federations, this implies that a common terminology is required, which is often hard to achieve (for example, the terms student, faculty, staff, and alum have slightly different semantics in the USA and in Europe). On the technical level, a LMS system can be broken down into two types of objects which are essential for the formulation of access control rules and policies, as shown in figure 1: – Learning Content Objects (LCOs) basically represent the course material created or coached by the trainers and consumed by the learners. This learning content is usually stored in object-oriented multimedia databases along with various metadata; in our solution, we extend the latter to include risk parameters that can be evaluated within access control policies. – Identity Information (IDI) provides relevant information about the LMS users. Traditionally, the attributes of each user profile object link it to one or more of the defined RBAC roles, which are more efficient to use in access control policies than long lists of usernames that would have the same privileges. However, in order to improve the dynamics of role definitions, we use individual user trust levels that complement the object risk parameters in our solution. However, as also shown in figure 1, an institution’s LMS often is a distributed system itself. In our scenario, the Leibniz Supercomputing Centre (LRZ) operates the multimedia databases and streaming servers of TUM’s LMS; these two services are also used by other LRZ customers, which necessitates an additional access control layer on the LRZ side. Furthermore, LCOs are managed by different content suppliers, and trainers as well as learners can be affiliated with more than one HEI. In practice, especially concerning the medicine study courses, the LMS must additionally support the handling of third party LCO vendors, external instructors, and guest students. SLAs exist between TUM and its external suppliers, and contractual frameworks, e. g. for the students, exist; because several study courses cannot be completed anymore without taking tests involving certain eLearning classes, guarantees regarding several classical quality of service parameters, such as service avaibility and mean time to repair, must be made. The typically short lifetime of eLearning classes, which is about 10–12 weeks, and the skew that all the classes start at the same day at the beginning of LRZ Student Lecturer Administrator Principal Access Control Mgmt (IDI) LCO Mgmt LMS web-based platform LCO1 LCO2 LCO3 learn TUM Student Lecturer Administrator Principal Access Control Mgmt (IDI) LCO Mgmt LMS web-based platform LCO1 LCO2 LCO3 learn LMU Student Lecturer Administrator Principal Access Control Mgmt (IDI) LCO Mgmt LMS web-based platform LCO1 LCO2 LCO3 learn create/update create/update create/update manage manage manage Operating of the TUM database Shared study course External Principal ? Fig. 1. A dynamic federated environment for eLearning services each semester, make traditional service level management next to impossible to handle on a per-service-instance-and-involved-party basis. Here, a dynamic TBAC approach, which considers the so-called trust level of each user, can greatly reduce the administrative overhead. We will provide details about the derivation of the trust level and its application for risk management in the next section. 3 A risk and trust based access control management approach for DFEs Due to the great variety of trust and risk metrics available on both, the algorithmic and the management level, we first define the terms and data structures we use throughout our work. We then discuss the workflows we use for the quantification of trust levels and risks. The implementation and application of the presented concepts are discussed in section 4. 3.1 Data structures for quantification and calculations In previous work, we have shown how the trust metric defined in our TBAC approach can be applied to solve authorization and usage control problems in federated environments (cp. [2, 3]). We have demonstrated that a quantification of the trust in a principal can be derived from examining service and action specific evidence of prior interactions; this reflects that, for example, an instructor who repeats the same eLearning class for the fifth time without any incidents may be considered more trustworthy than a first-time participant – please note that the selection and weight of input parameters is of course specific to each scenario. In the following, we summarize these results and introduce the variables we are using in this approach: Trust levels: A trust-based access control decision is primarily based on a set of access control policies P : {p1, p2, . . . , pn} that must define which subject set S : s1, s2, . . . , sn (i. e. roles or individual users) may perform which action set A : {a1, a2, . . . , an} (e. g. create, modify, delete, or download) on which resource set R : {r1, r2, . . . , rn} (an LCO is an example of such a resource) under which condition set C : {c1, c2, . . . , cn} at any point in time t within the cooperation lifecycle T . An example for the mapping to the rules contained in policies will be detailed below. We observe that trust, quantified as a user’s trust level tl, depends on the attempted actions, the involved resources, and the point in time: tl(s,A′ ,R ,t) = trust(s,A ′ , R ′ ,H, TD), where H represents the user’s reputation history and TD assigns weights to principal introductory protocols as discussed below. We normalize the result to a continuous scale in the range tl ∈ [0, 1], where 1 indicates absolute trust and 0 indicates absolute distrust. tl may also take the value of −1 in case the trust level cannot be determined, e. g. due to missing input parameters. Derived from our work presented in [2], we distinguish TD as follows: – Trust by reputation, i. e. the principal’s reputation is defined to be the quantification of conclusions drawn from observations of previous interactions that the principal was involved in, which must be witnessed either by the judging principal or relying on other sufficiently trusted entities. In this work we implement this mechanism by defining the current reputation ρ(s,t) = ρ(s,t−1) + e(A ′ , χs′ ,Hs), i. e. the new reputation value is to be derived from the previous reputation, adjusted by evidence e of the action set A ′ , which is reported with a witness-specific judging confidence of χs′ , under consideration of the user’s reputation history Hs, which serves as a smoothing factor to prevent too frequent automated changes of the user’s privileges. The formula for calculating ρ, with t0 being the first time when the principal requests access to resources, is weighted based on the number of transactions NA′ , i. e. the number of audited sets of actions within A ′ , at the given point of time as follows: ρ(s,t) = ρ(s,t0) + Pj=t−1 j=0 e(A ′ (j), χs′ (j), Hs(j)) Pk=t−1